Article 2287 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!caen!uwm.edu!wupost!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!dunix.drake.edu!acad.drake.edu!pk6811s
From: pk6811s@acad.drake.edu
Subject: Bunker progress
Message-ID: <1993Nov16.090412.1@acad.drake.edu>
Lines: 113
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
Date: Tue, 16 Nov 1993 15:04:12 GMT

More to report about Bunker, the self-repair program.  After reading my
own post it came to me that I could eliminate the in-register/in-memory
problem and cut two more lines by using the 'rp' pointer serve double
duty.  Both as a pointer for summing partner's b-operands and as a pointer
in the kill/restore part.  It is both outside the code and is set every
time through the monitoring loop, so it is perfect for that purpose.

It is also now more resistant to single decrements in the monitoring
loop, which previously caused the pair to self-destruct.  The 'set'
line will kill itself if it is decremented, and the 'jmn.a' line
will now jump one line too far back if it is decremented.

'rp' is positioned immediately before 'rkill'.  This is to kill
any spl-zeros created as part of a spl-jmp bomb on 'rkill'.

One thing I forgot to mention was the use of three dat's at the
end, which seems excessive.  When attacked by a spl-zero carpet,
the processes tend to move past the last line where they are
lost.  Having three (more would be better) dat's at the end gives
some protection (but not enough).

I am also trying it by booting only one copy into core, using
the original source as the second copy - hey it's supposed to be self-
repairing right?

Here is the latest version, sans decoy.

;redcode-94
;name bunker
;kill bunker
;author P.Kline
;strategy self-repair pair [94]
space    equ 4000
boot     equ 0
rp       equ (rkill-1)
copyf    dat #(re+1)
copyt1   dat #(re+1+space+boot)
copyt2   dat #(re+1+boot)

rkill    mov    re,>rp                ; kill partner
         mov    rc,>rclr+200          ; wait for him to die
         mov    <rkill+space,<rp      ; restore partner
         spl    set+space,<-1004
set      mov    initrp,@1             ; initialize b-op total and pointer
         sub.ba <rp,rp                ; subtract partner's b-operands
         jmn.a  @0,@rkill             ; check for zero-sum
rclr     mov    rc,>200               ; slow core-clear
         jmp    set,>rclr+200         ; advance core-clear a bit
initrp   dat    #0-388,#re-rp+1+space ; a = b-op sum,  b = ptr to partner
rc       dat    <2667,#1              ; core-clear bomb
re       dat    <2667,#space+1-rkill  ; erase partner and pointer back to self
         
start    mov #0,rclr+boot+space+200   ; offset core-clears, so we don't
         mov #100,rclr+boot+200       ; overwrite both partners at the same time
         spl 1                        ; create 12 processes
         mov -1,0
         spl 1
         spl 1
         mov <copyf,<copyt1           ; copy 2nd partner
         spl s2
         jmp set+space+boot           ; start 'em up
s2       jmp set+boot
         end start

Here are the latest results from StormKing:

Bunker                 %W/%L
------                 -----
A-stounding            56/30
Beholder's Eye v1.7    45/51
Sphinx v5.1            39/46
Plasma                 37/54
JustTakingALookSee     32/65
Grep v1.1              21/77
tiny                   20/76
Fire Storm v1.1        18/80
ttti                   18/82
NC II                  17/81
Medusa's v6            11/88
Like Rabbits!           9/82
Rave 3                  9/91
rontgen                 8/91
Rave                    6/94
Sylvester               4/92
Fast Food v2.1          2/97
death                   2/98
Snake                   1/98
RotLD TNG 2             0/97

I should count ties as wins, since for self-repair programs ties
are a 'moral' victory :-)

Bunker's weaknesses as I see them:

  vampire attack  - if the processes jump into the pit before repair, they 
                    are lost.

  spl-zero-carpet - if processes move into the carpet past the last line
                    of partner, they are lost.

  RotLD/Hydra     - if there are an even number of bombers, they tend
                    to overwrite both partners.

  paper           - eventually both partners will come under attack at
                    the same time.

Looks like it's time for a '94 version of AntiVamp.  Should be worth
a lot of points on stormking-94 :-)  Then maybe a spl-zero core-clear
followed by dat to address the paper problem.  Yeah I think that could
be fitted in - maybe just one more line.

Paul Kline
pk6811s@acad.drake.edu